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Background 

The  DoD  has  a  long  history  of  developing  and  testing  electronic  warfare  (EW)  systems  dating  back  to 
World  War  II.  Over  this  period  each  of  the  Services  has  established  test  facilities  and  internal  test 
processes  designed  to  test  and  evaluate  a  wide  range  of  EW  systems.  While  each  Service’s  facilities  and 
procedures  are  tailored  to  match  unique  Service  requirements,  the  overall  process  for  testing  EW  systems 
is  similar  across  the  Services. 

The  DoD  Electronic  Warfare  Test  Process,  using  a  combination  of  modeling  and  simulation  with 
measurement  facility,  system  integration  laboratory,  hardware  in  the  loop,  installed  system,  and  open  air 
range  testing,  is  designed  to  make  the  most  of  existing  T&E  technologies  and  resources  to  provide  a 
comprehensive  evaluation  of  EW  systems.  The  process  is  a  building  block  approach  designed  to  build 
upon  the  strengths  and  minimize  the  weaknesses  of  each  of  the  available  test  resources.  However,  even 
with  this  process,  there  are  two  interrelated  areas  of  particular  concern  in  EW  effectiveness  testing: 
problems  associated  with  correlating  and  interpreting  EW  test  results,  and  availability  of  appropriate 
resources  at  the  right  levels  of  fidelity  to  support  required  T&E  activities. 

The  Joint  Advanced  Distributed  Simulation  (JADS)  Joint  Test  and  Evaluation  (JT&E)  was  chartered  to 
evaluate  the  use  of  Advanced  Distributed  Simulation  to  enhance  the  EW  Test  Process  and  address  the 
problems  identified  above.  A  key  aspect  of  this  effort  is  the  development,  using  existing  test  facilities,  of  a 
linked  test  environment  with  which  to  conduct  the  JADS  EW  test.  JADS,  in  conjunction  with  the  DoD 
CROSSBOW  Committee,  conducted  the  Threat  Simulator  Linking  Activities  Study,  to  specify  a  joint  test 
environment  for  electronic  warfare  testing,  a  subset  of  which  will  be  implemented  to  support  the  JADS 
EW  test. 

ADS  in  the  EW  Test  Process 

Using  ADS  to  link  models,  simulations,  and  actual  hardware  in  real-time,  it  is  easy  to  postulate  an  ADS 
test  environment  that  combines  the  available  test  resources  used  in  the  EW  test  process  to  produce  an 
enhanced  test  environment  to  support  EW  system  T&E. 

Conceptually,  this  integrated  test  environment  could  support  all  phases  of  the  EW  system  life  cycle.  It 
would  act  as  a  force  multiplier,  leveraging  test  resources  not  normally  available  to  the  tester  at  a  given 
stage  of  development  to  allow  higher  fidelity,  more  operationally  realistic  testing  earlier  in  the 
development  and  test  process. 

During  concept  exploration,  high  fidelity  real-time  digital  models  of  the  proposed  EW  system  could  be 
linked  with  mission  level  models,  hardware  in  the  loop  and  open  air  range  assets,  and  human-in-the-loop 
simulators  to  provide  a  high  fidelity,  dynamic  “test  before  you  build”  capability  for  evaluation  of  the 
system  under  more  realistic  operational  conditions.  System  specifications  could  be  directly  evaluated  and 
optimized  against  operational  performance,  giving  the  EW  system  evaluators  a  direct  link  between  system 
specifications  and  operational  requirements.  Measures  of  Performance  (MOPs)  could  be  established  early 
to  ensure  they  accurately  represent  operational  requirements  and  they  could  be  collected  in  a  virtual 
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environment  that  replicates  the  operational  environment  using  the  actual  test  assets  that  would  be  used 
later  in  formal  DT&E  and  OT&E. 

As  the  EW  system  development  progresses  through  the  Program  Definition  and  Risk  Reduction,  and 
Engineering  and  Manufacturing  Development  stages,  emerging  hardware  could  be  substituted  for 
modeled  components  of  the  EW  system,  allowing  incremental  evaluation  of  the  developmental  system  in 
an  operationally  realistic  test  environment.  This  process  could  allow  system  performance  to  be  evaluated 
directly  against  established  MOEs  and  MOPs  in  the  event  critical  EW  system  specifications  fluctuate  due 
to  changes  in  the  threat  or  specified  performance  goals  cannot  be  achieved.  When  the  EW  system  is  ready 
for  OT&E,  the  evaluators  will  already  have  strong  insight  into  the  performance  of  the  system  in  an 
operational  environment.  Actual  test  and  evaluation  scenarios  could  be  selected  based  upon  known  areas 
of  concern  identified  during  earlier  linked  testing.  Test  scenarios  could  be  rehearsed  in  the  ADS 
environment  prior  to  field  testing  to  further  optimize  and  refine  valuable  field  test  missions.  The  linked 
test  environment  could  be  used  directly  in  OT&E  to  investigate  areas  where  field  testing  is  impractical 
(e.g.,  pilot  end  game  maneuvers  during  missile  engagements  and  evaluations  requiring  large  numbers  of 
assets  that  cannot  be  practically  assembled  on  a  test  range).  After  system  fielding,  the  linked  test 
environment  could  be  used  to  assess  the  EW  system’s  continuing  viability  in  the  changing  threat 
environment  to  refine  requirements  for  system  upgrades  or  follow-on  systems  and  to  evaluate  the 
effectiveness  of  proposed  system  modifications. 

Finally,  the  ADS  linked  test  environment  would  close  the  gap  between  training  and  testing.  Field 
operators  could  be  trained  in  the  linked  test  environment  and  participate  in  system  evaluations,  enhancing 
evaluators’  understanding  of  system  performance  by  the  end  user.  In  addition,  the  linked  test 
environment  could  provide  high  fidelity  training  tools  for  such  areas  as  mission  rehearsal  and  tactics 
development. 

Threat  Simulator  Linking  Activities  (TSLA)  Study 

The  purpose  of  TSLA  was  to  specify  a  design  approach  for  an  EW  T&E  environment  consisting  of  a 
combination  of  live,  virtual,  or  constructive  players.  This  study  developed  requirements  for  electronically 
networking  existing  digital  simulations,  hardware  in  the  loop  facilities,  installed  system  test  facilities,  and 
open  air  ranges  to  enhance  DoD  EW  T&E  capability.  The  study  was  designed  to  leverage  previous  and 
current  linking  efforts  to  design  a  dynamic  and  reactive,  closed-loop  T&E  capability  for  federated  and 
integrated  EW  systems.  Other  key  attributes  of  the  network  design  include  theater-specific  lay-down 
flexibility,  realistic  battlefield  densities  at  actual  frequencies,  hardware-hardware  interaction  fidelity,  and 
end-to-end,  cause-and-effect  quantification  of  EW  test  results.  The  study  was  scoped  to  concentrate  on  the 
radio  frequency  spectrum  due  to  the  large  number  of  facilities  and  assets  devoted  to  testing  in  this 
spectrum. 

Phase  I  of  this  effort  surveyed  previous  and  ongoing  initiatives  in  ADS  as  related  to  EW  T&E  facilities. 
Capabilities,  limitations,  and  applications  of  ADS  to  augment  the  existing  or  projected  federated  infrastructure 
were  be  identified  and  documented.  Phase  II  of  the  effort  specified  the  requirements  for  a  linked  environment. 
Phase  in  developed  preliminary  design  specifications  of  the  ADS  network. 

TSLA  was  sponsored  by  the  DoD  CROSSBOW  Committee  which  provided  technical  direction  and 
management  review  for  this  effort.  JADS,  the  lead  DoD  technical  organization  was  responsible  for 
project  execution  and  management.  Georgia  Tech  Research  Institute  (GTRI)  conducted  the  study.  Test 
facilities  and  ranges  from  all  three  Services  participated  in  the  study  and  acted  as  a  steering  committee  for 
the  study. 

ADS  Survey  Results 

The  study  team  surveyed  the  major  EW  test  facilities  and  ranges  to  baseline  existing  and  projected 
capabilities  relative  to  technical  requirements  for  implementing  an  EW  ADS  test  environment.  Key 


requirements  included  (1)  previous  linking  experience,  (2)  reactive  scenario  generation,  (3)  real-time 
instrumentation,  and  (4)  real-time  data  reduction,  analysis,  display,  and  archiving. 

Previous  Linking  Experience:  The  survey  concluded  all  the  hardware  in  the  loop  and  installed  system  test 
facilities  had  either  past  or  on-going  experience  with  distributed  simulation  and  a  few  of  the  facilities  had 
experience  with  the  High  Level  Architecture.  Open  air  ranges  had  minimal  experience. 

Reactive  Scenario  Generation:  Scenario  generation  requirements  include  the  capabilities  to  support  non- 
scripted  scenarios,  target  injection,  ECM  injection,  dynamic  terrain  masking,  and  clutter  injection.  The 
survey  concluded  these  capabilities  are  generally  available  at  hardware  in  the  loop  facilities  and  some 
installed  test  facilities.  Open  air  range  threat  simulators  generally  do  not  have  dynamic  target,  ECM, 
terrain  masking,  and  clutter  injection  capabilities,  although  there  are  on-going  efforts  to  provide  some  of 
these  capabilities. 

Real-Time  Instrumentation:  Instrumentation  requirements  include  the  ability  to  monitor  the  RF 
enviromnent,  internal  system  operations  monitoring,  ECM  RF  output  monitoring,  and  ECM  effects 
monitoring.  The  survey  concluded  the  ability  to  monitor  and  interpret,  in  real-time,  the  RF  environment 
and  RF  ECM  signals  was  not  available  at  most  facilities.  Several  facilities  have  on-going  upgrades  to 
provide  these  capabilities. 

Real-Time  Data  Reduction,  Analysis,  Display,  and  Archiving:  All  the  facilities  surveyed  had  existing 
capabilities  to  support  real-time  test  scenario  visualization  and  real-time  data  archiving.  All  had  some 
capability  to  perform  real-time  data  reduction  and  analysis  for  a  limited  number  of  measures  of 
performance. 

In  general,  the  TSLA  survey  concluded  a  test  environment  consisting  of  hardware  in  the  loop  and 
installed  system  test  facilities  could  be  constructed  using  existing  capabilities.  However,  the  construction 
of  a  large-scale  joint  test  environment  would  require  infrastructure  upgrades  at  most  of  the  surveyed 
facilities.  The  remainder  of  the  study  assumed  that  participating  facilities  would  make  the  appropriate 
upgrades  to  their  facilities. 

ADS  Network  Requirements 

The  conceptual  EW  test  enviromnent  and  its  associated  information  flows  are  shown  in  Figure  1.  To 
simplify  the  figure,  all  possible  assets  have  not  been  included,  however,  all  assets  were  considered  during 
the  generation  of  the  requirements.  In  the  model,  the  divisions  are  made  along  functional  breaks  and 
nothing  has  been  implied  concerning  facilities  or  the  distribution  of  assets. 

The  implementation  of  the  model  is  based  on  the  concept  of  encapsulation.  The  first  level  of 
encapsulation  recognizes  the  fact  that  many  assets  are  inherently  analog  devices  (e.g.,  radio  frequency 
(RF))  which  require  some  amount  of  instrumentation  and/or  analog-to-digital  conversion  before  the  asset 
can  interact  across  a  digital  network.  The  distributed  simulation  community  defines  three  types  of  assets: 
Live,  Virtual,  and  Constructive.  While  each  of  these  may  normally  exist  in  their  own  laboratory  or  range 
setting,  when  they  are  interacting  in  a  distributed  enviromnent,  they  must  all  also  “exist”  in  the  data 
domain.  Live  and  virtual  assets  are  almost  always  analog  systems  and  will  need  to  be  encapsulated  in 
order  to  participate  in  a  distributed  test.  Hence,  for  live  and  virtual  assets,  it  is  necessary  to  provide 
certain  instrumentation  which  will  convert  the  normal  inputs  and  outputs,  by  which  these  assets  usually 
interact,  into  digital  data.  The  distributed  environment  imposes  additional  Instrumentation  requirements 
on  live  and  virtual  assets  for  quality  assurance  (QA)  functions. 

Constructive  systems  may  already  be  digital  in  nature,  however,  in  some  cases  legacy  constructive 
simulations  may  need  additional  hardware  and/or  software  to  be  properly  encapsulated  as  an  entity. 

Newly  developed  constructive  simulations  may  be  coded  to  directly  take  advantage  of  the  entity 
encapsulation  model. 
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Figure  1.  Conceptual  Model  of  a  Linked  EW  Test  Environment 


In  each  case,  the  collection  of  data  from  an  asset  (live,  virtual,  or  constructive),  and  the  required 
instrumentation  to  interface  to  the  data  domain  shall  be  considered  to  be  an  entity.  This  approach  to 
entity  definition  permits  the  data  interface  to  an  entity  to  be  the  same,  regardless  of  whether  it  is  live, 
virtual,  or  constructive. 

In  order  to  thoroughly  explain  the  details  of  entity  encapsulation,  along  with  the  various  signal  injection 
and  monitoring  devices,  a  live  radar  is  considered  in  a  detailed  example.  A  live  radar  interacts  with  its 
environment  through  the  RF  domain.  In  certain  cases  (e.g.,  a  live  asset  within  the  normal  operating  space 
of  the  radar)  all  radar-to-asset  interactions  take  place  in  the  RF  domain  and  no  data-domain  conversions 
are  necessary.  Because  no  digital  data  are  exchanged,  live  entity  to  live  entity  interactions  in  the  RF 
domain  at  the  same  location  are  not  considered  to  be  interactions  within  the  scope  of  this  environment. 

In  other  cases  (e.g.,  the  radar  interacts  with  assets  which  are  not  within  the  normal  operating  space  of  the 
radar,  or  the  radar  interacts  with  a  virtual  asset)  radar-to-asset  interactions  cannot  take  place  in  the  RF 
domain.  Therefore,  the  radar  must  interact  with  these  assets  in  the  data  domain.  This  type  of  interaction 
is  considered  to  be  a  valid  interaction  within  the  scope  of  the  environment.  Figure  2  shows  an  example  of 
the  encapsulation  of  a  radar  entity. 

The  encapsulation,  in  addition  to  containing  the  actual  radar  asset,  may  also  contain  pre-measured  data 
(e.g.,  antenna  pattern),  signal  injection  equipment  (e.g.,  target  injection),  dynamic  monitoring  equipment 
(e.g.,  mode  monitor),  and  QA  monitoring  equipment  (e.g.,  RF  mode  monitor).  Fundamental  to 
encapsulation  are  the  various  monitors  and  signal  injection  units  that  are  required  for  data  conversion. 

The  function  and  data  requirements  for  these  are  included  in  the  specification. 
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Figure  2.  Encapsulation  of  Radar  for  Insertion  in  Data  Domain. 


The  second  level  of  encapsulation  adds  the  control  structures  that  allow  an  entity  to  function  in  a 
distributed  environment.  This  encapsulation  level  recognizes  the  fact  that  many  facilities  are  already 
organized  around  a  common  network  gateway  and  explicitly  supports  this  type  of  organization.  The 
encapsulation  is  composed  of  a  network  interface,  a  facility  controller,  and  one  or  more  encapsulated 
entities.  The  facility  encapsulation  is  shown  in  Figure  3.  A  network  interface,  a  facility  controller  and 
one  or  more  associated  entities  are  collectively  considered  to  be  a  facility. 


Figure  3.  Facility  Encapsulation 


The  following  entity  types  have  been  identified  as  potential  entities  for  an  EW  test  environment.  The 
specification  defines  the  encapsulation  of  each  of  these  entity  types  and  the  associated  data  requirements: 


Radar 

Early  Warning  Radar  (EWR) 
Height  Finder  Radar  (HFR) 
Target  Tracking  Radar  (TTR) 
Target  Acquisition  Radar  (TAR) 
Airborne  Interceptor  Radar  (AIR) 
Missile  Warning  Radar  (MWX) 
Threat 

Active  Missile 
Command  Guided  Missile 
Artillery 

Semi-active  Missile 
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Jammer 
Towed  Jammer 

Radar  Warning  Receiver  (RWR) 

Chaff  Dispenser 
Miscellaneous 
Platform 
C3 

Stand-Alone  Environment  Monitor 
Communication  Electronic  Countermeasure 
Facility  Controller 
Test  Director  Facility 


The  sharing  of  data  between  entities  is  another  concept  which  must  be  understood  to  understand  the 
feasibility  of  such  an  environment.  Key  to  this  concept  is  the  difference  between  the  sharing  of  static  and 
dynamic  data.  Pre-computed  or  static  data  required  by  entities  participating  in  the  test  shall  be  distributed 
to  the  entities  on  media  prior  to  the  federation  execution.  Data  in  this  category  includes  radar  cross 
section,  radar  and  ECM  antenna  patterns,  chaff  bloom  characteristics,  terrain  and  clutter  maps,  and 
operating  mode  definitions  for  all  emitters  in  the  federation.  During  the  test,  only  dynamic  or  reactive 
data  is  passed  between  the  entities.  Instead  of  attempting  to  perform  analog  to  digital  conversions  of  all 
emissions,  only  digital  words  or  pointers  representing  the  operating  modes  of  the  entities  is  passed  and  the 
injection  systems  recreate  the  modes  using  the  stored  definitions.  This  approach  to  data  sharing  and 
distribution  reduces  the  required  bandwidth  between  facilities  and  increases  the  latency  budget  for  the 
exchanges. 

For  the  simulated  engagement  to  proceed  properly,  the  location  and  orientation  of  each  entity  must  be 
known  to  other  entities  in  the  simulation.  In  an  EW  test,  there  are  certain  sensor  entities  (e.g.,  radar) 
which  produce  perceived  position  estimates  of  the  targets  they  detect.  There  are  essentially  two  types  of 
position  that  must  be  considered:  true  position  and  perceived  position.  The  true  position  of  an  entity  is 
reported  either  by  the  software  which  simulates  the  entity,  or  by  the  instrumentation  which  observes  the 
actual  location  of  the  entity  (e.g.,  reference  radar).  The  true  position  report  includes  the  3-dimensional 
position  and  3-dimensional  orientation  of  an  entity  relative  to  a  specified  coordinate  system.  The 
perceived  position  of  an  entity  is  reported  by  a  sensor  entity  which  is  an  active  participant  in  the 
distributed  EW  test.  These  sensors  are  capable  of  producing  reports  of  perceived  location  which  include 
various  combinations  of  range,  azimuth,  elevation,  and  Doppler. 

The  environment  requirements  also  include  system  requirements  for  the  various  monitors  and  injection 
systems,  however,  these  capabilities  are  assumed  to  be  part  of  the  facility  infrastructure  and  are  not  further 
specified.  Requirements  are  also  identified  for  the  various  environment  operating  modes,  timing 
accuracy,  predictive  filtering  or  dead  reckoning  to  predict  location  of  entities  between  position  updates, 
and  system  level  requirement  for  the  connecting  networks.  Finally,  the  specified  EW  test  environment  is 
designed  to  be  compliant  with  the  High  Level  Architecture. 

Control,  Display,  and  Reduction  Capability 

All  test  facilities  have  inherent  capabilities  for  test  control.  These  capabilities  have  been  designed  around 
the  internal  architecture  of  the  facility  and  the  entities  represented  in  the  facility.  A  joint  EW  test 
environment  which  links  various  test  facilities  must  have  the  capability  to  provide  for  overall  control  of 
the  environment  and  to  interface  with  the  controllers  of  individual  facilities.  The  requirements  for  an 


environment  control,  display,  and  reduction  capability  are  divided  between  the  existing  facility  controllers 
and  a  test  director  entity. 

A  Facility  Controller  entity  was  defined  to  permit  access  to  and  control  of  entities  within  a  test  facility 
without  requiring  that  each  individual  entity  interface  be  HLA  compliant.  Additionally,  the  Facility 
Controller  shall  be  the  physical  and  logical  connection  point  for  the  network  to  all  of  the  entities  within 
the  facility.  Many  facilities  are  already  organized  around  a  common  network  gateway  that  explicitly 
supports  the  use  of  a  facility  as  the  physical  point  of  connection  to  the  network  and  as  a  logical  control 
point  for  the  entities  within  its  purview.  The  facility  controller  is  the  abstraction  that  allows  all  entities  to 
properly  respond  to  commands  fi'om  the  Test  Director  Facility.  The  facility  controller  may  also  abstract 
certain  elements  of  each  entity  into  its  own  function. 

The  Test  Director  Facility  is  responsible  for  monitoring  and  controlling  all  test  activities  during  a  test. 

All  data  transmitted  over  the  network  shall  be  made  available  for  use  by  the  Test  Director  Facility. 

This  information  shall  be  reduced,  processed  and  displayed  to  keep  the  Test  Director  informed  as  to  how 
the  test  is  progressing  and  to  assist  the  Test  Director  in  determining  what  actions,  if  any,  are  required  to 
alter  the  test  sequence. 

The  Test  Director  Facility  monitors,  (1)  data  necessaiy  to  analyze  the  quality  of  the  test,  and 

(2)  data  necessary  to  evaluate  the  performance  and/or  effectiveness  of  the  System  Under  Test  (SUT). 

Quality-of-test  data  includes  (1)  scenario  visualization  data,  e.g.,  scenario  map,  threat  laydown,  target 
position  versus  time,  and  threat  mode  versus  times;  (2)  quality  assurance  data,  e.g.,  SUT  response  versus 
time,  filter  center  plot  board,  verified  emitter  mode  versus  time,  and  verified  SUT  response  versus  time; 
and  (3)  network  status  data,  e.g..  Built  In  Test  results  and  the  results  of  entity  latency  measurements. 

SUT  data  includes  SUT  modes,  threat  track  files,  ECM  tables,  blanking  statistics,  and  output  power 
characteristics. 

The  Test  Director  Facility  controls  the  test  execution  by  providing  measurement  scripts  to 
instrumentation, 

configuring  the  network,  and  transmitting  commands  to  the  affected  nodes.  To  automate  certain 
measurements,  the  Test  Director  Facility  shall  supply  measurement  scripts  to  particular  instrumentation 
systems.  The  Test  Director  Facility  shall  be  responsible  for  initializing  network  nodes  and  maintaining 
the  status  of  the  network.  Commands  processed  by  the  Test  Director  Facility  include  controlling  the  test 
execution  (e.g..  Start  test.  Stop  test.  Pause  test,  and  Initialize  test),  and  reconfiguring  Test  Director 
displays  (e.g.,  type  of  data  to  display,  and  size  of  a  display  window). 

The  requirements  for  both  the  Facility  Controller  and  the  Test  Director  Facility  are  similar  and  have  been 
specified  as  the  Control,  Display,  and  Reduction  Software  Segment  (CDRSS)  of  the  environment.  Figure 
4  shows  the  five  capabilities  and  the  internal  and  external  interfaces  of  the  CDRSS.  The  CDRSS  can  exist 
in  two  distinct  configurations.  The  configuration  located  at  the  Test  Director  Facility  shall  support  all 
network-level  functions  including  monitoring  of  all  network  entities  data  and  health  status  and  controlling 
state  transitions  of  each  entity  in  the  environment.  The  Node  Executive  (NE)  configuration  shall  support 
the  minimum  requirements  of  a  facility  controller.  These  include  monitoring  local  entity  data  and  health 
status,  controlling  entity  states,  and  reporting  data  and  status  information  on  the  real-time  network. 

CDRSS  has  three  external  interfaces.  The  Real-Time  Network  Interface  is  responsible  for  all  data 
communication  between  the  entity  and  the  real-time  network.  All  data  associated  with  the  encapsulation 
of  the  entity  shall  be  transmitted  over  this  interface.  The  protocol  for  data  transmission  shall  conform  to 
the  High  Level  Architecture  (HLA)  interface  specification.  The  Operator  Interface  supports  the  human 
operator  interaction  with  the  real-time  network  entity.  This  interface  shall  be  implemented  as  a  graphical 
user  interface  (GUI)  designed  for  real-time  applications.  Emphasis  shall  be  placed  on  displaying 
information  in  a  format  that  can  quickly  and  easily  be  detected  by  the  operator,  and  a  simple  menu 


hierarchy  to  permit  quick  access  to  control  commands.  The  Facility /Entity  Interface  is  responsible  for 
receiving  the  raw  data  from  the  facility  or  entity  instrumentation  that  is  necessary  to  perform  the  local 
data  reduction  function  and  to  provide  data  required  by  other  entities  on  the  real-time  network. 


Real-Time 

Network 


Facility /Entity 


External  Interface 
Internal  Interface 


Note  1 :  not  required  for  TDF  configuration 
Note  2;  optional  forNE  configuration 


Figure  4:  Control,  Display,  Reduction  Software  Segment 


Implementation  of  the  Joint  EW  Test  Environment 

At  this  time,  there  are  no  plans  to  implement  a  Joint  EW  Test  Environment  over  the  full  complement  of 
EW  test  facilities  owned  and  operated  by  the  Services.  Although  individual  test  facilities  can  use  the 
concepts  and  specifications  produced  by  the  TSLA  study  to  guide  their  individual  infrastructure  updates 
and  to  support  limited  linking  with  other  facilities,  a  full  implementation  would  require  centralized 
management  to  plan  and  allocated  resources  to  develop  the  capabilities,  upgrade  the  facilities,  establish 
the  network,  and  implement  the  Test  Director  Facility. 

The  JADS  Electronic  Warfare  Test  will  implement  a  subset  of  the  environment  between  two  existing  test 
facilities,  the  Air  Force  Electronic  Warfare  Evaluation  Simulator  (AFEWES)  and  the  Navy’s  Air  Combat 
Environment  Test  and  Evaluation  Facility  (ACETEF)  and  the  JADS  Test  Control  and  Analysis  Center 
(TCAC),  which  will  serve  as  the  Test  Director  Facility  and  will  host  several  simulations  used  in  the  test. 
Two  linked  tests  are  planned  using  this  environment  for  1998  and  1999.  This  implementation  will  serve 
as  both  an  evaluation  of  the  utility  of  ADS  to  the  EW  Test  Process  and  an  evaluation  of  the  Joint  EW  Test 
Environment  concept. 
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